Today's communications environment is rich with information providers, with the World Wide Web being the outstanding example. Modern communications technologies allow a Web user to download a software file to his computing device from one Web site, listen to a live music broadcast from another, all the while browsing through other Web sites searching for meaningful content. At the same time, the user may hold a telephone conversation, possibly with a live video feed, with another user using the Web to provide the communications connection. The user's computing device may also serve as a “gateway,” providing communications services for another local computing device. This latter situation is common in home environment where all communications come through a central desktop computing device which then shares its communications capabilities with other devices in the home. Each of these activities creates one or more “flows” of communications coming into the user's computing device. In the typical set up, the user's device has just one communications link handling all of these flows simultaneously. The connection is typically a modem connection, or more and more commonly, a DSL (Digital Subscriber Line) or cable modem link.
The communications link has a limited total capacity, or “bandwidth,” which it shares among all of the communications flows coming into the user's computing device. Typical modern communications protocols support this sharing and, when the sum of the bandwidth demands of all of the incoming flows exceeds the total bandwidth available on the shared communications link, the protocols allocate the bandwidth. This allocation is performed automatically by the protocols and eventually arrives at a more-or-less “fair” distribution of bandwidth among the competing communications flows. However, a “fair” distribution is rarely what the user wants. In a first example, when the user is working from home on one computing device that serves as a gateway for a second device, then the user may wish his work activities to take precedence in their bandwidth demands over a second user's entertainment activities.
Another reason for not wanting a “fair” distribution of bandwidth among the incoming communications flows is based on differences in bandwidth characteristics among various flows. The extent to which these differing characteristics are supported strongly affects the user's perception of the flows' quality. To illustrate, consider three “benchmark” communications flows. First, a telephone conversation is termed “real-time” because the listening parties are very sensitive to latency, that is, to delays in the communications process. Both the sending and the receiving flows display this sensitivity to latency. A packet of a remote speaker's voice information whose delivery is delayed by just half a second, for example, cannot be played upon its arrival. Rather, if the packet has not yet arrived when the time comes to play the voice contained in the packet, the listener may hear a “pop.” When the late packet finally does arrive, it is worthless and is discarded. Real-time flows are often characterized by a fairly constant use of bandwidth over time. (The bandwidth used may vary somewhat over time with differing efficiencies achieved by compression algorithms.) Downloading live music is another example of a real-time communications flow, in this case involving only a receiving flow that is sensitive to latency. Receiver-side buffering can be used to relieve some, but not all, of the sensitivity to latency.
For a second benchmark communications example, consider a Web browser. The browser's communications flow is termed “interactive” because the amount of bandwidth demanded and the latency desired depend upon the user's actions at any one time. When the user clicks on an icon or otherwise requests a new page of information, the response may involve a large amount of information being sent to the user's computing device. The information is preferably delivered as quickly as possible so that the user does not have to wait long for it. After receiving the information, however, the user typically spends a while reviewing the information before making another request. During this period of user review, the browser's bandwidth demands are very low or nil. Thus, an interactive communications flow may be characterized by periods of little or no bandwidth demand interspersed with periods where large bandwidth and low latency are desirable.
The third benchmark communications flow example involves a file download. The user requests that a large amount of information be sent to the computing device. Unlike in the interactive flow example, the user is not staring at the screen of the device waiting for the download to complete. Rather, the user is paying attention to other communications flows. Because this type of communications flow is not directly tied to the user's immediate perceptions, it is termed a “background” flow. While this type of flow may demand enormous amounts of bandwidth, the demand may be satisfactorily met with small amounts of bandwidth spread over a long period of time.
When a user's computing device is simultaneously receiving examples of all three benchmark flows, it is clear that a “fair” allocation of bandwidth does not satisfy the user's requirements. Instead, an ideal allocation of bandwidth would give real-time flows as much bandwidth as they need as soon as they need it. Interactive flows would receive the remainder of the bandwidth when responding to the user's requests for information and would receive little or no bandwidth otherwise. Background flows would use any bandwidth not needed by the real-time and interactive flows. An ideal allocation would change moment by moment with changes in the bandwidth demands of the flows and would not waste any bandwidth due to allocation inefficiencies.
Such an ideal allocation is possible when all of the communications flows coming into the user's computing device originate at one sending device. The sender controls all of the flows and can allocate bandwidth accordingly. This case is the rare exception, however. A major benefit of today's communications environment is the proliferation of content providers and a user's ability to receive content from multiple providers to create a combined presentation unique to the user. This case of multiple, simultaneous providers is one consideration leading to the development of QOS (Quality of Service) protocols.
QOS protocols are used by senders and receivers to negotiate various aspects of their communications. When fully deployed, QOS protocols would be very useful for allocating bandwidth among competing incoming communications flows. If even a few devices do not yet implement full QOS protocols, however, the benefits of QOS can quickly become elusive. The user's computing device would not be able to depend upon the fact that all of its communications peers adhere to QOS and so would have to make other arrangements. Full QOS deployment is taking place only very slowly for many reasons. First, QOS protocols must be standards agreed upon by all participating parties. The protocol standardization process is slow because the needs of all participants must be accommodated without impeding the advanced capabilities of a few participants. Second, once the new QOS standards are set, all communicating devices must be upgraded to implement the standards, a process that can take years. Finally, because of their complexity, a full suite of QOS protocols may require more processing power to implement than some of today's smaller devices can afford.
What is needed is a way for a receiver computing device to autonomously change the allocation of bandwidth among its incoming communications flows.